home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / tads2exe.zip / TADSVER.DOS < prev    next >
Text File  |  1992-12-20  |  8KB  |  169 lines
  1. This file contains a list of changes that have been made to TADS
  2. since the initial 2.0 release.  Most of the changes are fixes to
  3. bugs, so they don't change the documented behavior, but a few, as
  4. explained below, add new functionality to TADS.
  5.  
  6.  
  7. 2.0.11  12/20/92  bug fixes
  8.  
  9.   - Goto statement labels were occasionally not released properly,
  10.     resulting in spurious internal errors.
  11.  
  12.   - The 'continue' statement did not work as documented in 'for'
  13.     statements.  Instead of jumping to the re-initializer expression,
  14.     as it now does, the 'continue' incorrectly jumped to the condition.
  15.  
  16.   - The run-time is slightly smaller and faster.
  17.  
  18.   - The compiler did not process locals correctly when multiple disjoint
  19.     blocks within a function or method had locals, and a later block had
  20.     fewer locals than a previous block (yes, it's a somewhat obscure bug).
  21.  
  22. 2.0.10  No such release (to synchronize with Mac release levels)
  23.  
  24. 2.0.9  12/12/92  MS-DOS bug fixes and new features
  25.  
  26.   - The file selector dialog displayed incorrect information when a
  27.     directory name that used all 11 characters was displayed.
  28.  
  29.   - The file selector now saves and restores all default directory and
  30.     disk information.  The current disk, and the current directory on
  31.     each disk, will be the same when TR is terminated as it was when
  32.     TR was first run.  (This applies to TDB as well.  It's particularly
  33.     important for TDB, because TDB needs to have the source files in
  34.     the current working directory if an absolute path was not specified
  35.     with -I.)
  36.  
  37.   - NEW FEATURE:  the new user function commandPrompt, if provided by
  38.     the user's game program, will be called prior to each player command.
  39.     If the commandPrompt function is provided, the default ">" prompt is
  40.     NOT displayed; if no commandPrompt function is defined, the default ">"
  41.     is used.  This should not affect existing games at all, unless a game
  42.     defines its own function, method, or property called commandPrompt
  43.     having a different purpose.  The commandPrompt function returns no
  44.     value.  The function takes a single argument:  a number, indicating
  45.     the type of command that the system is prompting for:
  46.  
  47.        0  - normal command
  48.        1  - command after invalid word (allowing "oops" to be used)
  49.        2  - disambiguation (after "which x do you mean..." question)
  50.        3  - command after askdo (after "what do you want to x?")
  51.        4  - command after askio
  52.  
  53.     Note that the default prompt in all cases is simply ">", and in all
  54.     cases a new command can be entered.  However, when the type code is
  55.     2, 3, or 4, a question has just been displayed by the run-time, so
  56.     the commandPrompt function may want to suppress any pre-command
  57.     information or prompt text.  Case 1 is generally identical to case 0.
  58.  
  59.   - NEW FEATURE:  A new built-in function has been added, which allows
  60.     the game program to suppress the display of text that would normally
  61.     be displayed with double-quoted strings or the say() function.  The
  62.     function is called outhide(), and it takes one argument:  a flag,
  63.     indicating whether to suppress or re-enable the display of output.
  64.     If the flag is true, output is suppressed; if the flag is nil, output
  65.     is re-enabled.  Any output that occurs between outhide(true) and
  66.     outhide(nil) is discarded.  However, outhide(nil) returns a value
  67.     indicating whether any output did in fact occur since the call to
  68.     outhide(true); this allows you to determine if any output would have
  69.     occurred, even though the output is not seen by the player.  Note
  70.     that this is effectively the same mechanism used by the player command
  71.     parser for noun disambiguation using the verDoXxx and verIoXxx
  72.     methods, as described in the TADS author's manual.  There is no way
  73.     to recover the text that was suppressed by outhide(); the text is
  74.     simply discarded, so the only information available is whether any
  75.     text was generated.
  76.  
  77. 2.0.8  12/03/92  (tc/tdb 2.0.7, tr 2.0.8) MS-DOS bug fixes and minor changes
  78.  
  79.   - The display initialization code was incorrectly attempting to clear
  80.     a zero-line region of the display.  This resulted in extremely long
  81.     delays on some computers (due to an incorrect BIOS call made by TADS).
  82.  
  83.   - NEW FEATURE:  When the keyword $$ABEND is typed as the entire command,
  84.     the run-time immediately terminates and returns to DOS.  This emergency
  85.     escape is provided so that TR can be terminated if the game somehow
  86.     gets into a state where a more graceful exit is not possible.
  87.  
  88.   - NEW FEATURE:  The parser now calls two new optional methods in the
  89.     game program.  These new methods are intended to help speed up the
  90.     identification of words when many objects have the same vocabulary.
  91.     If the new methods are not present, behavior is the same as before,
  92.     so existing games will run unchanged.  The new methods are validDoList
  93.     and validIoList; they are associated with the "deepverb" object for
  94.     the current command.  They are called with three parameters:  the actor,
  95.     the prep, and the other object (indirect object for validDoList and
  96.     direct object for validIoList; the value of the parameter will be nil
  97.     if not applicable).  These methods are called prior to the disambiguation
  98.     pass (using verDoXxx/verIoXxx), and prior to testing any objects with
  99.     validDo/validIo.
  100.  
  101.     The return value of validDoList/validIoList is a list of all of the
  102.     valid objects for the verb.  It is fine for these methods to return
  103.     *too many* objects, since each object is still tested with validDo
  104.     (or validIo) and the appropriate verDoXxx/verIoXxx methods.  Generally,
  105.     these methods should simply return a list of all of the accessible
  106.     objects in the actor's current location (or the actor's location's
  107.     location), plus a list of all of the "floating" objects (which use
  108.     methods for the location properties).
  109.  
  110.     An appropriate definition for validDoList in the deepverb object
  111.     appears below:
  112.  
  113.        validDoList(actor, prep, iobj) =
  114.        {
  115.            local ret;
  116.           local loc;
  117.  
  118.        loc := actor.location;
  119.        while (loc.location) loc := loc.location;
  120.        ret := visibleList(actor) + visibleList(loc)
  121.               + global.floatingList;
  122.        return(ret);
  123.        }
  124.  
  125.     This same definition (with the name changed) is appropriate
  126.     for validIoList in deepverb.  This returns a list of all of the
  127.     objects visible in the current location, plus the global list of
  128.     all floating objects; this should be a superset of the list of
  129.     accessible objects in most games.  The only verbs that normally
  130.     requires a different value of validIoList/validDoList are verbs
  131.     such as "ask" and "tell" that allow any object (whether accessible
  132.     or not) to be used as indirect objects; for these, simply use this
  133.     definition:
  134.  
  135.        validIoList = nil
  136.  
  137.     This takes advantage of the reverse compatibility feature:  when the
  138.     method returns nil, all objects with matching vocabulary are used.
  139.  
  140.     The one additional game change required to take advantage of this
  141.     new feature is that global.floatingList must be built during
  142.     initialization.  This can be done easily with the following loop:
  143.  
  144.        global.floatingList := [];
  145.        for (o := firstobj(floatingItem) ; o ; o := nextobj(o, floatingItem))
  146.           global.floatingList += o;
  147.  
  148.     This should be placed in the preinit or init function.  Note that
  149.     all objects which have location methods should be declared to be
  150.     of class floatingItem:
  151.  
  152.       class floatingItem: object;
  153.  
  154.     This class doesn't do anything except serve as a flag that an
  155.     object should be placed in the floatingList.
  156.  
  157. 2.0.7  12/01/92  MS-DOS bug fix release
  158.  
  159.   - The run-time occasionally missed the \ in an escape sequence in
  160.     output strings.
  161.  
  162.   - The run-time couldn't operate in 132 column mode.
  163.  
  164.   - The run-time abnormally terminated in the file selection dialog
  165.     when the dialog box was exactly filled.
  166.  
  167. 2.0.6  11/24/92  first general MS-DOS TADS 2.0 release
  168.  
  169.